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METHOD FOR ESTABLISHING A VIRTUAL PATH CAPABILITY IN A FRAME 

RELAY NETWORK 



Technical field 

The present invention relates generally to the Frame Relay 
5 networks and in particular to a method for establishing a 
Virtual Path capability in a Frame Relay network. 

Background 

The purpose of a Frame Relay network is to provide an end user 
with a high speed Virtual Private Network (VPN) capable of 
10 supporting applications with large bit rate transmission 
requirements. 

First, a frame relay system must provide services to delimit 
and align frames on the channel by using flags identifying the 
beginning and ending of a frame. Secondly, the frame relay 

15 system must support virtual circuit multiplexing and 
demultiplexing through the use of a Data Link Connection 
Identifier (DLCI) in the frame. Such a DLCI identifies a 
virtual connection on the channel at a user to network or 
network to network interface. Consequently, a DLCI specifies a 

20 data link layer entity to/from which information is 
delivered/received and which is to be carried in frames by data 
link layer entities. The DLCI field may be either unstructured 
or structured. A structure to DLCI field may be established by 
the network at the user to network interface or at a network to 

25 network interface subject to negotiation or bilateral 
agreement . 

In the example illustrated in FIG.l, a source user 10 wants to 
communicate with a destination user at address 64.2.3.4. 
Router 12 which receives the traffic to this destination looks 
30 up its routing table and sees that this address is mapped with 
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DLCI 27. It puts the contents in the frame and indicates the 
DLCI 27 before sending this frame over Frame Relay network 14. 
The frame is received by a first switching node 16 which maps 
with its routing table to the DLCI 992 and relays the frame to 
a second switching node 18. Then, this second switching node 
maps to the DLCI 35 and sends the frame to router 20 which 
forwards finally the frame to destination user 22 at address 
64.2.3.4 stored in the user payload contained in the frame 
without any changes within the Frame Relay network. 

As described above, the DLCIs are pre-mapped to a destination. 
The switching nodes inside the network consult their routing 
table and route the traffic to the proper output port. 
Therefore, different DLCIs are required to establish different 
virtual circuits from a switching node in the network even 
though all this virtual circuits are connected to a same 
switching node over a single trunk. As the DLCI field has in 
most implementations only 10 bits and most of the bit 
combinations are reserved or used for the user information, 
there are few DLCIs available. Furthermore, connectionless 
operations could be implemented inside the network with the 
requirement that the frames arrive at the right port designated 
by the destination identification. 
Summary of the invention 

Accordingly, the object of the invention is to achieve a method 
enabling several virtual circuits using the same trunk between 
two switching nodes of a Frame Relay network to have a single 
Data Link Connection Identifier (DLCI) . 

Another object of the invention is to achieve a protocol 
enabling several virtual circuits using the same trunk between 
two switching nodes of a Frame Relay network to be aggregated 
in a single virtual path. 
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The invention relates therefore to a method for establishing a 
Virtual Path (VP) capability in a Frame Relay network wherein 
frames are transmitted over a plurality of virtual circuits 
from a first switching node to a second switching node, this 
5 method consisting in transmitting from the first switching node 
to the second switching node a control message with a Data Link 
Connection Identifier (DLCI) having a predetermined value, the 
control message defining a virtual path aggregating at least 
two ones among the plurality of virtual circuits and containing 
10 the identification of the virtual circuits aggregated in the 
defined virtual path. 

According to a specific aspect of the invention, the control 
message includes a field (VCID) containing one byte for the 
identification of each virtual circuit aggregated in the 

15 virtual path and a portion containing a Source Virtual Circuit 
IDentifier (SVCID) field corresponding to the input adapter 
used by the virtual circuit in the first switching node, a 
Source Port IDentifier (SPID) field corresponding to the input 
port used by the virtual circuit in the first switching node, a 

20 Destination Virtual Circuit IDentifier (DVCID) field 
corresponding to the output adapter used by the virtual circuit 
in the second switching node and a Destination Port IDentifier 
(DPID) field corresponding to the output port used by the 
virtual circuit in the second switching node. 

25 Brief description of the drawings 



The above and other objects, features and advantages of the 
invention will be better understood by reading the following 
more particular description of the invention in conjunction 
with the accompanying drawings wherein : 

- Fig. 1 represents a block-diagram of a Frame Relay network 
showing a virtual circuit established between a source 
user and a destination user. 
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- Fig. 2 represents a block-diagram of a Frame Relay network 
wherein several virtual circuits established between a 
first switching node and a second switching node have been 
aggregated in a same virtual path according to the method 
of the invention. 

- Fig. 3 represents schematically a diagram showing the 
protocol exchanges between the two switching nodes of Fig. 
2 for establishing a virtual path according to the method 
of the invention. 

Fig. 4 is the format of the control message sent from the 
first switching node to the second switching node. 
Fig. 5 is the format of the data frame after that the 
virtual path between the two switching nodes has been 
established by using the method according to the 
15 invention. 

- Fig. 6A and Fig. 6B represent respectively the source 
table and the destination table of the switching nodes 
which are updated by a control message according to the 
principles of the invention. 
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Detailed description of the invention 

As already mentioned in reference to Fig. i, a virtual 
connection is established between switching node 16 and 
switching node 18 by using a Data Link Connection Identifier 
(DLCD 992. Now, it is assumed that several virtual circuits are 
established between switching node 16 and switching 18 (or 
between two other switching nodes of Frame Relay network 14). 
The invention is implemented in the manner described hereafter. 

Fig. 2 illustrates the implementation of the invention wherein 
switching node 16 is linked to the external elements via the 
vxrtual circuits VC2, VC4 on one link L0 and VC1, VC3 and VC5 
on another link LI. To switching node 18 are attached virtual 
circuit VC1 on link L2, virtual circuit VC5 on link L3 and 
vxrtual circuits VC2, VC3 on link L4 . Virtual circuit VC5 
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inputing switching node 16 is a connection with another 
switching node 24. It must be noted that the external links can 
be defined as ports but may be also trunks connected to other 
nodes of network 14. 

5 As illustrated in Fig. 2, switching node 16 connects to 
switching node 26 which is a backbone node, itself connected to 
another backbone switching node 18, this one being finally 
connected to switching node 28. As illustrated in the figure, a 
virtual path VP 12 according to the principles of the invention 

10 is built with the virtual circuits VC1, VC2, VC3 between 
switching nodes 16 and 18. Virtual circuit VC5 which 
corresponds to a class of service different from the class of 
service of virtual circuits VC1, VC2, and VC3, is not 
aggregated in VP 12 and shows the coexistence of standards 

15 virtual circuits with virtual paths according to the invention. 
Note that though the invention is implemented between two 
switching nodes 16 and 18 including intermediary switching 
nodes 26 and 28, it could be implemented between two adjacent 
nodes as well. 

20 It is clear that is necessary to configure correctly the 
assignment of each virtual circuit to its new virtual path into 
both switching nodes 16 and 18 as the intermediary switching 
nodes should remain transparent. Therefore, a protocol is 
defined to support the data exchange and the negotiation 

25 between the two nodes. Such a protocol is illustrated 
schematically in Fig. 3. 

First of all control message having specific DLCI 999 is sent 
from switching node 16 to switching node 18. Note that value 
999 is included in the values which are reserved for the layer 
30 management of the frame bearer service. On the reception of 
this first control message, node 18 identifies that it is the 
aggregation control message with the DLCI value of 999. The 
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node records the chain of Vcs associated to the Virtual path 
identification DLCIn. Node 18 answers to node 16 by : 

An aggregation control message acknowledge positive if 
the Virtual circuits are operational and the Quality Of 
Service requested in the line with the authorized 
parameters. 

Or a rejected aggregation control message answer. The 
VCs will not be operational in aggregation mode. A 
status message could be included in this reject message 
in order to identify the reason. This message will be 
forwarded to the network management system for filing 
and analysis. 

No answers from node 18 may indicate that it did not 
correctly understand the request. Node 16 could start 
an error or expiration timer when it sends a 
configuration control message in order to inform the 
network management system of this error. 

In case a rejection message is received by switching node 16 or 
if no answer is received when the timer expires, no aggregation 
20 is performed. 

An acknowledge message is then transmitted to switching node 18 
in order to validate the aggregation if the confirmation is OK. 
Otherwise, an error or acknowledge rejection is sent by 
switching node 16 depending upon the message received from 
switching node 18. This one could also start a timer after 
sending its confirmation message for waiting for the 
acknowledge from switching node 16. In such a case, an error 
detection is rised at the expiration of the timer. 



Fig. 4 illustrates the complete format of the control message 
sent from the first switching node to the second switching node 
in the protocol according to the invention. This control 
message has a defined data structure and uses a specific DLCI 
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(for example DLCI 999) value which has been defined as a 
negotiation flow between the two nodes. The assignment of this 
DLCI between two nodes of the network is made through the 
network or inter-node protocol. There could be a specific DLCI 
5 assigned for each logical connection between two nodes of the 
network where the aggregation needs to be activated. Each field 
of the control message has the following meaning : 

VPID : the Trunk Virtual Path Identifier 
AGGT aggregation type 14 bits (0-13) 
10 0,1 : defines nb of bytes used for merging VC filed 

in data frame (1, 2 or 3 bytes) corresponds 
to the size of the VCID 
2,3 : number of bytes for Source Port definition 
(6,14, 22 or 30 bits) 
15 4,5 : number of bytes for Destination Port 

definition (6,14, 22 or 30 bits) 
6,7 : define the size of the QoS Field : 0, 1, 2 or 

3 bytes (Flow ID + QoS) 
8 to 12 : indicate if it is a single command or a 
20 multiple command and in this last case, the 

number of VCs included 
13 : bit spare 

VCID : Trunk VC identifier 



A control message is used to set up only one VP and one or 
25 several VCs in that VP. It must be noted that at each time one 
or some new VCs are established between the two nodes, a 
control message is sent in order to include the new VC(s) in 
VP. Therefore, a control message never contains many VC 
identifications . 

30 In each control message, the field after DLCI 999 of 10 bits is 
the Virtual Path IDentifier (VPID) . This field will be used as 



the common DLCI N for the transmission of the frames belonging 
to all aggregated VCs between the two nodes. 

The AGGT field of 14 bits defines the aggregation type and mode 
corresponding to the aggregated VCs defined after this field. 
It allows to align the boundary of the VCs definition to an 
exact number of bytes. 

The Virtual Circuit Identification is put in the VCID field. 
This field contains as many bytes as there are VCs to be 
aggregated. Then, for each VC, the following fields define the 
Source Virtual Circuit IDentifier (corresponding to the input 
adapter of switching node 16), the Source Port IDentifier 
(corresponding to the input port switching node 16), the 
Destination Virtual Circuit IDentifier (corresponding to the 
output adapter of switching node 18), the Destination Port 
Identifier (corresponding to the output port of switching node 
18) and the QoS field which defines Priority, Queue, Traffic 
type, Flow ID (per VC) . 

Fig. 5 shows the structure of a data frame according to the 
principles of the invention. The header is in fact the VP 
identification which fits into the DLCI field. Then, the VC 
identification of the VC number i, that is VCID(i) is put as 
the first byte of the data field which is ended by the Frame 
Check Sequence (FCS) field. Thanks to the control message of 
Fig. 4, the receiving switching node knows to which port and on 
which VC this data frame should be mapped. 

Each time a control message is sent between the two switching 
nodes, an identification table shown in Fig. 6A and 6B is 
updated in each node. In the sending node, the source table 
maps, for each couple VP/VC respectively identified by VPID and 
VCID to the Source VC identifier and the Source Port 
Identifier. Similarly, in the receiving node, the destination 



table maps for each couple VP/VC, to the Destination VC 
identifier and Destination Port identifier. 



Each time a frame is received on an input adapter in switching 
node 16 a lookup is performed in the source table to check 
5 whether this frame should be encapsulated into a VP structure 
or transmitted as a normal VC frame. Similarly on the receive 
adapter of switching node 18 a lookup is performed on each 
received frame to check whether this frame is a normal VC frame 
which will be mapped using the classical forwarding mechanism 
10 or is a VP encapsulated frame which will be forwarded to the 
defined port using the defined VC given by the line pointed by 
this frame VP/VC identification. 



Note that any virtual circuit which is no more used should be 
deleted from a virtual path. For this, it is possible to 

15 reserve a supplementary field in the control message (e.g. in 
VCID field) . Another method consists in using in the first 
switching node, a time counter for measuring the time of 
non-activity of each VC. When the contents of the time counter 
reach a predetermined threshold, this means that the VC may be 

20 removed from the VP. If so, it is sufficient to overwrite in 
the source table of the first switching node, the VC 
identification to be removed by a new VC identification. Then, 
the information of removing the VC from the destination table 
is transmitted in an internode protocol message from the first 

25 switching node to the second switching node . 



The preferred method which enables some VCs or the entire VP to 
be cancelled consists in using a specific control message 
wherein bit 13 of the AGGT field is set to 1 . If all the VCID 
fields following the AGGT field have all their bits set to 0, 
30 this means that the entire VP is removed. If only some VCID 
fields have all their bits set to 0, this means that only the 
corresponding VCs are removed from the VP. Such a procedure can 
be very useful in case of re-configuration . 
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CLAIMS 



1. Method for establishing a Virtual Path (VP) capability in a 

Frame Relay network wherein frames are transmitted over a 
plurality of virtual circuits from a first switching node 
5 (16) to a second switching node (18) ; 

said method being characterized in that it comprises 
the step of transmitting from said first switching node to 
said second switching node a control message with a Data 
Link Connection Identifier (DLCI) having a predetermined 
10 value, said control message defining a virtual path 

aggregating at least two ones among said plurality of 
virtual circuits and containing the identification of the 
virtual circuits aggregated in said defined virtual path. 

2. Method according to claim 1, wherein said control message 
15 includes a field (VCID) containing one byte for the 

identification of each virtual circuit aggregated in said 
virtual path. 

3. Method according to claim 2, wherein said control message 

includes for each virtual circuit being aggregated in said 
20 virtual path, a portion containing a Source Virtual Circuit 

IDentifier (SVCID) field corresponding to the input adapter 
used by said virtual circuit in said first switching node 
(16), a Source Port IDentifier (SPID) field corresponding 
to the input port used by said virtual circuit in said 
25 first switching node, a Destination Virtual Circuit 

IDentifier (DVCID) field corresponding to the output 
adapter used by said virtual circuit in said second 
switching node (18) and a Destination Port IDentifier 
(DPID) field corresponding to the output port used by said 
30 virtual circuit in said second switching node. 



FR 9 99 079 10 




10 



15 



4. Method according to claim 3, wherein said second switching 
node (18) transmits back to said first switching node (16) 
a confirmation message if the aggregation of said virtual 
circuits in said virtual path is possible or a rejection 
message if such an aggregation is not possible. 

5. Method according to claim 4, wherein said first switching 
node (16) sends an acknowledgment message to said second 
switching node (18) after receiving said confirmation 
message . 

6. Method according to claim 5, wherein a timer is started by 
said second switching node (18) when this one transmits 
back said confirmation message to said first switching node 
(16) in order to activate an error detection if said timer 
expires before said acknowledgment message has been 
received by said second switching node. 

7. Method according to any one of claims 4 to 6, wherein a 
timer is started by said first switching node (16) when 
this one sends said control message to said second 
switching node (18) in order to activate an error detection 
if said timer expires before either said confirmation 
message or said rejection message has been received by said 
first switching node. 

8. Method according to any one of claims 3 to 7, wherein said 
first switching node (16) includes a source table 
containing the values of said Source Virtual Circuit 

IDentifier (SVCID) and said Source Port IDentifier (SPID) 
for each virtual circuit aggregated in said virtual path, 
and said second switching node (18) includes a destination 
table containing the values of said Destination Virtual 
30 Circuit IDentifier (DVCID) and said Destination Port 
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IDentifier (DPID) for each virtual circuit aggregated in 
said virtual path. 



9. Method according to any one of said claims 1 to 8, wherein 
the identification of said virtual path defined in said 

5 control message is used as Data Link Connection Identifier 

(DLCI) for each data frame using a virtual circuit 
aggregated in said virtual path. 

10. Method according to any one of claims 2 to 9, wherein some 
ones of said VCID fields of said control message 

10 identifying virtual circuits aggregated in said virtual 

path contains only bits set to 0, indicating that the 
virtual circuits identified by said VCID fields set to 0 
have to be removed from said virtual path. 

11. Method according to claim 10, wherein all VCID fields of 
15 said control message are set to 0, indicating that said 

control path is cancelled. 

12. A system comprising means adapted for carrying out the 
method according to any one of the preceding claims . 
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METHOD FOR ESTABLISHING A VIRTUAL PATH CAPABILITY IN A FRAME 

RELAY NETWORK 



Abstract 



Method for establishing a Virtual Path (VP12) capability in a 
5 Frame Relay network wherein frames are transmitted over a 
plurality of virtual circuits from a first switching node (16) 
to a second switching node (18), such a method consisting in 
transmitting from the first switching node to the second 
switching node a control message with a Data Link Connection 
10 Identifier (DLCI) having a predetermined value, this control 
message defining a virtual path aggregating at least two ones 
among the plurality of virtual circuits and containing the 
identification of the virtual circuits aggregated in the 
defined virtual path. 



15 FIG. 2 
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